👈 Test his PR on Binder

@yuvipanda @sgibson91 I made some changes to the requirements.txt, that I thought would clear up the following issue, but it's persisting. When I made my initial pull request yesterday, the image built successfully on binder. But when I changed the image tag in the Configurator and load a new server, the added packages are not available on the hub, despite a supposed successful build. I changed the requirements.txt to remove a couple of lines where packages were repeated and submitted a new pull request. On binder, this image builds successfully - though it does at the end say 'failed to connect to event stream' rather than loading the image. Despite this 'successful' build, again in the jupyterhub, after replacing the docker tag in the Configurator, the packages in requirements.txt are not available in the hub.

Any clue what may be happening?

the packages in requirements.txt are not available in the hub

Did you restart the user server?

though it does at the end say 'failed to connect to event stream'

This is more to do with JavaScript running in the browser than it is about successful builds. Most likely, your pod was up and running in the cluster but something prevented the browser redirect. A couple of things you can try here is just refreshing (you should immediately see "Found built image") and making sure ad-blockers are not active on mybinder.org (they can interfere).

thank you @sgibson91. The second issue was an ad blocker.

I did restart the server and just tried it again and same problem. I try to load the altair package in a notebook or in the python console and it states that the module can't be found.

@JILPulvino hmm, so the mybinder link (from #3 (comment)) doesn't have a working altair either, so at least it's not specific to the hub

Ahh, I didn't think to test in the binder, was just ensuring that the build was correct.

Maybe an environment.yaml file and installing via conda will help? https://altair-viz.github.io/getting_started/installation.html

@sgibson91 there's a Dockerfile here already that brings in common packages from the pangeo images. I just opened #4 which stops inheriting from the pangeo image, and just uses repo2docker. This means we'll have to explicitly list all the packages we want - but that's probably ok?

Would there be an issue if we moved to using a environments.yml file to compile instead as well? We are looking to use such a file in some of our other repos to take advantage of conda being able to specify R packages and environments. This also goes to @damianavila question about generalizing.

@JILPulvino absolutely, you can just use an environment.yml file instead. Just remove the Dockerfile and add an environment.yml file, and test it out on Binder with the button the bot gives you

(deleted a dupe comment from Yuvi ⬆️ )

Rethinking this one, as I said in the PR, I agree about going from simple to complex.
The requirements/environment file solution should be enough OK for now and if more complexity is needed later, a Dockerfile with the "proper" parent can be introduced in the future.